Skip to content

Conversation

rodrigoprimo
Copy link
Collaborator

Description

Now that support for PHP < 7.2 has been dropped in PR #2614, we can simplify the sniff code by defining the two different function signature formats as class constants. This was not possible before, as PHP < 5.6 did not support defining class constants as arrays.

Suggested changelog entry

N/A

@rodrigoprimo rodrigoprimo force-pushed the update-get-meta-single branch from 00496d4 to 2d204ca Compare October 16, 2025 13:13
Now that support for PHP < 7.2 has been dropped in PR 2614, we can simplify the sniff code by defining the two different function signature formats as class constants. This was not possible before as PHP < 5.6 did not support defining class constants as arrays.
Copy link
Member

@dingo-d dingo-d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just left one comment about the since tag.

@rodrigoprimo rodrigoprimo force-pushed the update-get-meta-single branch from 2f9ae1b to a09975d Compare October 17, 2025 11:29
Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rodrigoprimo !

Only remark I have left is that as support for PHP < 7.2 has been dropped, these new class constants could be defined with visibility and in this case, I'd recommend private visibility as the info is only relevant to this sniff.

Not a blocker though, as the pre-existing constants don't have visibility modifiers yet, so I expect that to be changed in a future PR anyway.

Only thing to remember about this is that the pre-existing constants must be declared as public and the visibility can't be changed until WPCS 4.0, while for new class constants like these, we can use the correct visibility from the get-go.

@rodrigoprimo
Copy link
Collaborator Author

rodrigoprimo commented Oct 20, 2025

Thanks, @jrfnl! Defining the visibility of the two new constants to private now makes sense to me, as you suggested, so that we don't have to wait for the next major to change them from public to `private. I pushed a new commit implementing this change.

Sorry @dingo-d for pushing the change right after you submitted another review for this PR.

Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rodrigoprimo ! All good from me.

@jrfnl jrfnl added this to the 3.3.0 milestone Oct 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants